Webサービスのトラブルの現場 ~ Webサービスの今と昔 ~
今回はWebサービスによくあるトラブルを題材に実際にどのようにトラブルを解決していくかの勘所をお話します。
- Webサービスが突然落ちた
- RDBMSのコネクションが溢れる
- Webサーバのロードアベレージが青天井
トラブルは突然に
サーバのLAが青天
「まだ4桁はみたことがないです」
大小あれど必ず起きる
トラブルシューティングは花形である
「アドレナリンでてくるんすよ」
トラブル対応のコツ
PHP developerの人が多い
インフラの人はちらほら
マネージャーはちょっと
Agenda
自己紹介
PostgreSQLユーザ会
婚活パーティーの
フルPHPです
今日のPHPのはなしはここだけです
「アフィリエイトリンクから買ってください」
「いちばん大事な話が終わった」
Web Serverが死ぬのは日常茶飯事
DBとかに比べれば日常茶飯事
色んな理由で死ぬ
渋谷のスクランブルで聞きました
アプリケーションバグ
第一位
テストしましょう
E2Eテスト、ユニットテスト
stagingつくれるならE2E
HW障害
HDD、電源、NICと囲われる
冗長化は大事
Cloud Platformだとアプリでもできる
インフラ的には3台たてるのが理想
片方壊れたら1第で裁かないといけない
平均70%の負荷で片方落ちたら両方壊れる
falloverしてread replicaが1つしかない
アクセス過多
モニタリングしてますか？
してる人はいまからTwitterしててください
OS側の情報
最近のコンテナつかってるとsshしなくて見落としがち
Apache or nginxの情報
apacheのプロセスの情報が取れる
特定URLで情報が帰る
MySQL版が超大作
メトリクスが250個ぐらいある
いつおきた？今の情報しか取れないので時系列データ
zabbix, mackerel etc...
AWSならcloudwatch
Google
Azure monitor
運用は無駄金扱いされがち
トラブルのときに必要なので投資価値がある
PHPの実行情報
プロファイラ（FWについてたりする）
すげーでかいファイルを食わせるとメモリを食べるので注意
Webサイトの情報
URL監視、エンドポイント監視
「静的サイトでも落ちるときは落ちる」
Cloudwatchも最近URL監視に対応
もっと詳しく「そーだいさんのブログ 〇〇 監視」
おや、共有サーバの様子が？
スポンサーにGMOがいたりするのでほどほどにする
お隣さんがMySQL5.0にサブクエリ投げるとかして、MySQL止まる
AWS自体が詰まるとか
自分たちが悪くなくてもサービスが止まることはある
影響範囲を調べるのが大事
WebServerは死ぬので、死ぬ前提で準備することが大事
500台ぐらいあると毎日数台死ぬ
EC2の再起動、10分ぐらいかかる
Batchの突き抜け
SIerあるある
終わらないといけない時間までに時間が終わらない
朝のレジがあくまでにおわらないといけない売上集計バッチ
終わらないと開店できない
フィクション：8:50ぐらいに「レジが動かないんですけど」
定期実行のバッチがおわらない
手元PCより本番サーバーのほうが雑魚いパターン
sshだとswap発生するとcdで固まる
top帰ってこないしps帰ってこないからままならない
コマンド打てない
「あるんですよ？」
EC2で16GBあてないでしょ？4GBとかでしょ？
データ量が多いからバッチにしたい
php.iniにlimit_memoryを設定できるので起きる
limitに-1を設定して死ぬ
ある日のこと
php.ini見る
framework config見る
よしよし、と実行するとswapでる
phpのバッチの上にinisetされていた
バッチは監視されていない
非同期処理は忘れがち
PHPの処理がメモリで死んだとき、shoutdown handlerを設定しておかないと通知が来ない
「えっ、1ヶ月実行うまくいってないけど？」
実行結果を知りたい
例外で死んだときもわかる
アプリを変えずにバッチの死活監視できる
Goなのでバイナリおくだけ
いつ実行された？実行時間は？複数のバッチは？
Mackerelをメモが書ける。これをPHP
mackrelは5台まで無料
バッチの実行時間もわかるし、メタ情報が付与できるようにもなった
実行時間を集められれば、trdsqlで集計できる
サイトにアクセスできません！
こっから駆け足
「まず落ち着け」
一番大事
原因が様々
ユーザー「任天堂が悪い」
クライアントが駄目なパターン
JSがエンドポイントをたたけているか？
意外と監視してない
HTTP的にセキュアじゃないからブラウザがはじく
JS呼べない
ほかのJSとコンフリクトしてる
インターネット
DNSとかすぐ壊れる
8.8.8.8が動かなくなるとアプリは結構動かなくなる
Route53が障害起こると結構動かなくなる
google.comと8.8.8.8両方叩くのおすすめ
8.8.8.8だけDNSがおかしい
google.comは帰ってくるけど自分のはかえってこない、じゃあIPでたたいてみよう、となる
サーバサイド
前半話したので割愛
だいたいみんなサーバサイドから疑う。それは正しい
が、クライアントやインターネットが壊れることもある
サーバサイドなのかそうでないのか切り分けたいので監視をする
問題箇所を根拠を持って調べる
「ここは大丈夫」を剃り落としていく
チームで仕事をしているとなおさら（役割分担しよう）
クラウドでも死ぬ
制御できるところとできないところを知る
稼働率
99.9%
年間8.7時間しか止められない
「ビル全体が止まります」で保守できなかったりする
99.99%
年間停止52分
完全冗長化だけではむり
夜間体制メンバー、自動復旧
AWS見ると99.99%はほぼない
サービスがうたうならマルチリージョンとかCDNを複数用意するとかが必要になる
AWS「多分落ちません！落ちたらお金返します！」
落ちないわけではない
CDN
複数CDNつかってるところ、あまりない
殆どのサービスがCDNうごかなくなるとうごかない。JSとってこれないのでクライアントが動かない
コスト高いので割り切りも必要
RDBMS
cloudのfull managed DBはベンダーロックイン
変わりない
MySQLをインストールし直してすぐレプリを組める人、会社にいますか？
メール基盤が壊れた
障害が発生しました
「メールが飛ばないです」
急所を知る
急所が壊れると、ハイボール飲みながら治るの待つしかない
クラウドは便利。トレードオフは？
コントロールできないところを知っておく
それが壊れたときにはどうしよう？を考えられる
準備してなかったらできない
まとめ
便利になるということは、抽象化されたものである
よくわからんけどうごく
トラブルのときには仕組みを知っている必要がある
現場のトラブルを解決するのはあなただ
ソフトウェアエンジニアの仕事って何？
技術で課題を解決すること
トラブルは一番わかり易い課題
この機会に学んでください
QA
Appのトラブルは知覚の範囲外でおきる。知らないことに対してアンテナを建てることで工夫してることはありますか？
知らないことが問題になっているかどうか
知ってることで起きてる
テスト、ユニットテストがとおってればそれ
それOKなので死んだらしらないことでこわれてる
AWSの調子が悪そうならstatusを購読できたり、Twitterで知ってそうな人がつぶやいていることから知る